REMARKS 



Applicants have carefully reviewed the Office Action dated July 18, 2006. Applicants 
have amended Claims 1, 11, 19, 24 and 27 to more clearly point out the present inventive 
concept. Reconsideration and favorable action is respectfully requested. 

Claims 1, 4, 5, 6, 9, 10, 14, 15, 17-19, 22 and 23 stand rejected under 35 U.S.C. § 102(a) 
as being anticipated by Hartman, U.S. Patent No, 5,960,411. This rejection is respectfully 
traversed with respect to the claims as presently presented. 

The Examiner has made the following rejection with respect to the claims: 

In regards to claims 1, 4, 5, 6, 9, 10, 14, 15, 17-29, 22 and 23, 
Hartman discloses all the features of the instant claims. For example, 
Hartman teaches sending an order form with information already inserted 
for viewing or changing and which has not been viewed by the user before 
receipt of the order form (FIG 1C).; 

The Examiner's rejection basically states that Hartman discloses "all features of the instant 
claims." The Examiner cites one example in that Hartman teaches sending an order form with 
information already inserted for viewing or changing which has not been viewed by the user 
before receipt of the order form. The Examiner specifically refers to Fig. 1C. Applicant believes 
that a review of the Hartman patent in detail will be of assistance to the Examiner in 
understanding Applicant's position with respect to this reference. 

Hartman was faced with a problem that is described in the background of the invention. 
The portion of the background of the invention deals with this problem as set forth beginning at 
Column 2, Line 27 and extending to Column 2, Line 48. This portion of the specification is set 
out as follows: 

Although the shopping cart model is very flexible and intuitive, it has a 
downside in that it requires many interactions by the purchaser. For example, the 
purchaser selects the various items from the electronic catalog, and then indicates 
that the selection is complete. The purchaser is then presented with an order Web 
page that prompts the purchaser for the purchaser-specific order information to 
complete the order. That Web page may be prefilled with information that was 
provided by the purchaser when placing another order. The information is then 
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validated by the server computer system, and the order is completed. Such an 
ordering model can be problematic for a couple of reasons. If a purchaser is 
ordering only one item, then the overhead of confirming the various steps of the 
ordering process and waiting for, viewing, and updating the purchaser-specific 
order information can be much more than the overhead of selecting the item itself. 
This overhead makes the purchase of a single item cumbersome. Also, with such 
an ordering model, each time an order is placed sensitive information is 
transmitted over the Internet. Each time the sensitive information is transmitted 
over the Internet, it is susceptible to being intercepted and decrypted. 

Thus, it can be seen that the problem to be solved in Hartman was to more easily facilitate the 
placing of an order after selection of an item is complete with a reduced number of actions. 



To facilitate the placing of an order, Hartman utilizes what is referred to as a "single- 
action ordering" technique. This is specifically illustrated with respect to Figures 1A-1C. This 
system begins in Figure 1A wherein a web page is sent from a server system to a client system 
when a purchaser requests a review of detailed information about the item. When this is sent, 
there is provided, in one example, a summary description Section (101), a shopping cart section 
(102), a single-action ordering section (103), and a detailed description section (104). Of course, 
any of these sections can be omitted or rearranged, as set forth in the specification. Hartman 
states that: 

In general, the purchaser need only be aware of the item or items to be 
ordered by the single-action and of the single-action needed to place the order. 
(Column 4, Lines 14-17.) 

However, the single-action section is not necessarily provided in the web page presented to the 

user. This operation is set forth as follows: 

The server system, however, only adds the single-action ordering section 
when single-action ordering is enabled for that purchaser at that client system. 
(Column 4, Lines 24-26.) 

The purpose of this single-action ordering section is set forth specifically in Column 4, beginning 
at Line 31 as follows: 
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This example single-action ordering section allows the purchaser to 
specify with a single click of a mouse button to order the described item. Once 
the purchaser clicks the mouse button, the item is ordered, unless the purchaser 
then takes some action to modify the order. 

Thus, if single-action ordering is enabled, the web page of Figure 1A is presented to the user. As 

can be seen from Figure 1A, there is provided a button (103a), a purchaser identification 

subsection (103c), and (103d). In the specification, the Section (103b) indicates, that the ID is 

associated with an individual at a home location. The subsection (103 d) provides another 

location to learn more about the single-action ordering operation. However, other than the 

single-action ordering button (103 a), the information that is provided with that button to the user 

is set forth with the following restrictions: 

To reduce the chances of sensitive information being intercepted, the 
server system sends only enough information so that the purchaser is confident 
that the server system correctly identified the purchaser but yet not enough 
information to be useful to an unscrupulous interceptor. (Column 4, Lines 41-46.) 

The purpose of this additional information is to allow the purchaser to obtain various settings or 
obtain more information related to the single-action ordering. For example, if the purchaser 
wanted to verify the shipping address, the purchaser could select the hyperlink at information 
locating (103c). This is referred to as a "label" in the Spec. This might route the user to some 
type of login page to identify the purchaser. The purpose of this is so that sensitive information 
such as a shipping address is not sent just by accessing the web page. 

When a user selects the single-action ordering button, the steps that follow are set forth 
beginning at Column 4, Line 59. Initially, the client system sends a message to the server system 
requesting that the displayed item be ordered. The server system then provides the client system 
(not the user specifically) a new web page confirming receipt of the single-action order. This is 
illustrated in Figure IB. As such, the purpose of this operation is that the user can select the 
button (103a) resulting in completion of the order, i.e., the selected item by the user is first 
associated with web pages of Figure 1A and then will be purchased, i.e., some type of financial 
transfer of funds made, and then the product shipped to a pre-stored shipping address. 
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In order for single-action ordering to be enabled, the server system must have stored 
therein sufficient purchaser-specific order information for the client system to complete a single- 
action order (Column 5, Lines 17-20). If sufficient information is not present, then a web page is 
sent to the user to collect additional information that is needed. The server system may even 
require a purchaser to log in such that the identity of the purchaser can be verified before single- 
action ordering is enabled. 



To facilitate purchaser-specific ordering via the single-action order system, customer 
information must be pre-stored that includes purchaser-specific order information. This 
information is such as the name of the customer, billing information, shipping information. 
(Column 6, Lines 1-4.) There is also provided in the system a client identifier/customer table 
(212), set forth in Figure 2. The description and use of this identifier is set forth as follows: 

The client identifier/customer table 212 contains a mapping from each 
client identifier, which is a globally unique identifier that uniquely identifies a 
client system, to the customer last associated with that client system. The client 
system 220 contains a browser and its assigned client identifier. The client 
identifier is stored in a file, referred to as a "cookie." In one embodiment, the 
server system assigns and sends the client identifier to the client system once 
when the client system first interacts with the server system. From then on, the 
client system includes its client identifier with all messages sent to the server 
system so that the server system can identify the source of the message. The 
server and client systems interact by exchanging information via communications 
link 230, which may include transmission over the Internet. (Column 6, Lines 7- 
21.) 

It can be seen from this section that first, the customer is not necessarily identified; rather, what 
is identified is the client system. This is facilitated with the now well-known "cookie" concept 
wherein a code is disposed on a user's computer that can be retrieved whenever a connection is 
made to a particular server. For example, initial access to the home page of a particular vendor 
can result in that vendor's system accessing the user's computer and retrieving the cookie 
therefrom. This cookie has sufficient information that can be utilized by the vendor location 
server to map to a particular profile for that user. This may be as simple as a name, but it could 
contain other information that was placed in the vendor location server at the time of initial 
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setup. Thus, there must be some type of pre-stored profile of such at the vendor location server. 
Once the cookie is determined and a match or relational link exists at the server, this person is 
considered "logged in." At this point, however, the user has done nothing more than make a 
connection and, unknown to the user, the cookie has alleviated the requirement that the user log 
in to access various features of a particular system. One problem with this type of system is that 
the particular user does not have the ability to actually log in or take an action of inputting 
verification data, i.e., user name and password; rather, anyone who accesses this web page or 
web site on a particular physical system or client device will identify that system as associated 
with that user even though the user is not that identified at the server. Thus, it is the computer 
that transmits the identifier and not the user. 

With respect to the claims and this 35 U.S.C. § 102(e), a 102(e) rejection requires that 
each element or step of the claim be described in that document, such that the disclosure within 
the four corners of that document anticipate such invention. 

MPEP §2131 specifies that: 

A claim is anticipated if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single 
prior art reference. 

The Examiner has stated that the Hartman reference disclosed "all the features" of the claims. 
Thus, if one or more of the features, i.e., elements or steps, is not disclosed, then Hartman does 
not constitute an anticipatory reference. 

The first step of the claim requires that profile information be entered into a profile form 
at a user location disposed on the network prior to conduction of the on-line transaction between 
the user and the vendor. In Figure 3, and in the description associated therewith beginning at 
Column 6, Line 39, there is depicted the routine for enabling single-action ordering for a 
customer. This is facilitated if a customer desires to have single-action ordering as an option. 
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One method to facilitate this is for the server to prompt the customer through a web page for the 
purchaser-specific order information. Another way to achieve this is to basically save purchaser- 
specific order information that is collected when an order is placed in a conventional manner 
and, with a customer's consent enable the single-action ordering. The question is how does the 
client system become associated with the purchaser-specific information? Although this is not 
described in detail, what is described is that a "cookie" is utilized. In these type of systems, what 
occurs is that a server system, upon recognizing a request for a connection, will first look to see 
if the cookie exists on the client system and, if not, it will then place a cookie on that client 
system. In the event that there was no prior cookie disposed in the client system, what will occur 
is that a login page will typically be presented to a user. If a user has a login address, it will 
require the user to login. Once logged in, then the cookie on the user system will be associated 
with that particular user (assuming a prior purchaser-specific order information stored at the 
server). Alternatively, the cookie that is already associated with a user's purchaser-specific order 
information (assuming such is the case), that cookie can be placed on the user's computer. In 
any event, there will be some kind of relational link between a cookie on one or more client 
devices and that user's purchaser-specific order information. Therefore, there can be provided 
multiple cookies on multiple client devices that, when accessed, will be recognized by the server 
as belonging to that user, even though that user has not input that cookie or acquiesced to the use 
of the cookie or is even actually operating that client device. It is merely the turning on of a 
client system that allows the cookie to be transferred. This fact is recognized by Hartman in a 
statement beginning at Column 6, Line 67 to Column 7, Line 3, wherein it is stated that a 
purchaser might not want to allow the enablement of a single-action ordering in the event that a 
possibility exists for someone else utilizing that client's system. There is no disclosure in 
Hartman that in any way makes the cookie unique to a particular user but, rather, it is unique to a 
particular client system. Thus, from the standpoint of the first step of the process, Hartman does 
provide the ability to enter profile information of the user into a system but, there is no indication 
that this is input to a profile form. The only disclosure is that the user enters information in 
response to prompts. Thus, the statement that the profile information is entered into a "profile 
form" at the user location is not clearly taught by Hartman. 
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In the second step of the claim, there is the step of issuing to "the user" a unique code that 
represents the stored profile information. As noted hereinabove, in Hartman, a cookie is 
disposed on the user's computer. This cookie is unique, as the server must recognize this cookie 
and its association in some database on the server with respect to some purchaser-specific 
information. However, since this is a cookie system, there is no requirement that this be issued 
to the user; rather, it is issued to a client system and any user utilizing that system can gain 
access to the information. As such, the cookie is not issued to the user but, rather, it is issued to 
the client device which the user is using at that time. Further, Applicant believes that, although 
not disclosed in any detail, this cookie could be disposed on many computers at the same time or 
multiple cookies could be disposed on different client devices. In any event, this cookie is not 
issued to the user but, rather, to the client device. Further, the unique code is not issued in 
response to transmitting of the profile form; rather, it is issued to the client device as a result of 
logging in to the server. Further, Applicant believes that the cookie is disposed on the computer 
prior to the association being made. As such, Applicant believes that Hartman does not 
anticipate the concept of issuing to a user a unique code in response to transmission of the profile 
form. Further, Applicant believes that this particular cookie is only unique as long as the 
relational link is disposed within the server. If, for example, another user utilizes that client 
device and connects to the vendor's web site, it is believed that what would happen would be 
some type of prompt asking if the user is that particular user. Typically, this is of the type of 
prompt such as "Welcome John Doe, if you are not this person, please log in with your correct 
name." If another user is on the system and enters their log in, the cookie may not be changed 
but, rather, a relational link is changed. In any event, Hartman still does not meet the limitations 
of this step of the claim. 

The next step of a claim requires that, after the user has selected a particular product, the 
unique code is then provided to the vendor location during the on-line transaction. As such, the 
user has already selected the product and then, upon desiring to purchase the product, the user 
transmits or provides the code to the vendor location. In Hartman, the code, i.e., the cookie, is 
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provided to the vendor location upon the client device accessing the web site. There need be no 
selection or no on-line transaction initiated or even entered into or begun when this unique code 
is sent to the vendor location. Therefore, Applicant believes that the step of providing to the 
vendor location the unique code during the on-line transaction does not occur, as the unique code 
in Hartman must be transmitted before a web page is even transmitted to the user. Additionally, 
with respect to this step of a claim, the on-line transaction is one that requires a user to view a 
vendor payment form at the user location that represents the information about the transaction, 
and which payment form has information associated therewith that the viewer "must" view prior 
to completion of the on-line transaction. The Examiner has referred to Figure 1C with respect to 
this as support for his rejection. However, Figure 1C is a web page that is returned after 
completion of the on-line transaction. Thus, this form cannot be viewed prior to the completion 
of the on-line transaction. As such, clearly Hartman does not anticipate such step as it discloses 
and suggests an entirely different sequence or event. 

The next step of the claim requires that the stored profile information be provided to the 
vendor location from a second location upon receiving and processing the unique code. In this 
system, all of the profile information is contained at the server and, thus, there is no requirement 
to go through a second location. Further, the profile information is not provided "in response to" 
the processing of the unique code. As noted hereinabove, the unique code has been processed as 
a function of access to the web site. Thus, Applicant believes that the Hartman reference does 
not anticipate or suggest the step of providing the stored profile information to the vendor 
location in response to the receiving and processing of the unique code. 

In the last step, at least a portion of the stored profile information is inserted into the 
vendor payment form in respective fields. The only place that there is any remote suggestion of 
such an action is with respect to the original form that was sent to the user, as set forth in Figure 
1A. In this section, section (103), there is provided a button for the transaction and, in addition 
thereto, other information such as address information, links to express ordering, etc. Of the 
information, the only information that is noted is the name of the user in position (103b). 
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However, the requirement of this step is that, when the user receives the form (noting that this is 
not a payment form but, rather, an information page) for viewing after insertion, there is a 
requirement that this insertion follow the steps of selecting a product and then forwarding a 
unique code to the server for the purpose of initiating the on-line transaction, i.e., purchasing the 
product, and then a form sent back to the user already filled in. The information is inserted into 
the web page with the description of the product in Hartman prior to the user deciding to select 
that particular product. In Applicant's present method, the present inventive concept, as defined 
by the amended claims, requires the selection to have already been made, and the providing of 
the unique code is performed during the on-line transaction. 

Claim 1 and Claim 14, which is basically the corresponding system claim to Claim 1, 
both require that there be a selection step and then the step of providing the unique code during 
the on-line transaction to cause a form to be populated and then returned to the user. Hartman 
provides the code before any on-line transaction is initiated and then provides a populated 
information sheet on selection of a button merely for the purpose of reading the description of 
that product. This is a distinct difference of steps between the claims as amended and Hartman. 
As such, Hartman does not anticipate or obviate Applicant's present inventive concept, as 
defined by the amended claims. Therefore, Applicant respectfully requests withdrawal of the 35 
U.S.C. § 102(e) rejection with respect to Claims 1, 4, 5, 6, 9, 10, 14, 15, 17-19, 22 and 23. 

Claims 3, 7, 8, 13, 16, 20, 21 and 26 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable to Hartman in view of Rhoads. This rejection is respectfully traversed with respect 
to the amended claims. 

In the rejection, the Examiner basically states that "the combination of Hartman/ Rhoads 
teaches the instant claims" with no further discussion of exactly how the Examiner is applying 
both of these references to the claims. As noted hereinabove, Applicant believes that the 
Hartman reference does not disclose a number of elements or steps in the claims and, as such, 
Rhoads is not sufficient to cure those deficiencies. 
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With respect to Claims 3 and 16, these claims are directed toward the profile form being 
transmitted to the second location over a public switch telephone network. All that Rhoads 
teaches is, with respect to Column 3, Lines 45-55, a list can be printed either at home or at the 
grocery and then the user walks the grocery aisles and purchases these groceries in a 
conventional manner. In another embodiment, a list is sent via the internet or telephone for use 
by the grocer. However, there is no profile form that is disclosed as being sent in Hartman; 
rather, all Hartman does is prompt the user for information to populate a particular profile. As 
such, Applicant believes that the combination of Hartman and Rhoads does not anticipate the 
aspect of transmitting a profile form to the second location in combination with all of the other 
steps/elements.. 

With respect to Claims 7, 8, 20 and 21, these claims are directed toward the aspect that all 
the profile information be inserted into the vendor payment or only a portion of the profile 
information be entered into the profile form in an encoded form. The Examiner refers to Rhoads, 
Column 10, Lines 1-8 for support of this portion of the rejection. The cryptology that is utilized 
to enter information in an encoded fashion does not appear to be anticipated by this portion of 
the specification, as all this says is that the data utilizes encryption. However, the population of 
the form is not disclosed as being done in an encrypted manner, which population is to be viewed 
by the user. Thus, Applicant believes that Claims 7, 8, 20 and 21 are not obviated by the 
combination of Hartman and Rhoads. 

With respect to Claims 13 and 26, the Examiner indicates that the combination of 
Hartman and Rhoads teaches that the unique code is placed on a credit card. The Examiner 
refers to Rhoads, Column 1, Lines 35-40. This portion describes the "BEDOOP" code which is 
a sound. This portion describes that a credit card, the user's credit card, is placed in front of the 
desktop camera and a sound emits. In general, this invention utilizes a digital code that is hidden 
on an object and placed in front of the camera to extract this information. Thus, it could be that 
the profile information is actually coded thereon. However, this is nothing more than a code that 



AMENDMENT AND RESPONSE 

SN: 09/382,426 

Atty. Dkt. No. PHLY-24,732 



16 



is given to a user. There is no suggestion or motivation for a cookie to be disposed in a card that 
a user would have. First, in Hartman, there is no disclosure that the user has a code; rather, the 
server actually creates the code, possesses the code, and then stores it on the computer. This is 
not unique to a user but, rather, it is only unique to a particular client device and, through the 
relational link with the database, to that user's purchaser-specific order information. Since the 
user need not enter the information, there is no reason for the user to have such. As such, 
Rhoads does not appear to be a proper combination for this aspect of the invention. 

In view of the above, Applicant believes that the combination of Hartman and Rhoads 
does not anticipate or obviate Applicant's present inventive concept, as defined by the amended 
claims. Therefore, Applicant respectfully requests that the filing of 35 U.S.C. § 103 rejection 
with respect to Claims 3, 7, 8, 13, 16, 20, 21 and 26. 

Claims 11, 12, 24, 25 and 27 are rejected in view of Hartman and Official Notice. This 
rejection is respectfully traversed. 

Claim 11 requires that the second location (which is not described in Hartman) is a 
simple registration server. This server has a database of unique codes and unique ID numbers. 
Claim 11 has been amended to depend from Claim 5, as the unique ID numbers were disclosed 
in Claim 5. In Hartman, cookies are utilized. Hartman discloses only that the database 
associated with the cookies is disposed at the server and there is no discussion or suggestion that 
the cookies would be disposed elsewhere. Claim 1 requires that the profile information be 
provided from a second location to the vendor location, i.e., two different locations. There is no 
reason noted in Hartman why a cookie, i.e., code, would be disposed anywhere other than on the 
server. As such, Applicant believes that the Rhoads reference does not cure this deficiency. 
With respect to Claim 12, this being dependent on Claim 11, suffers the same deficiency with 
respect to that disclosed with respect to Claim 11. Claims 24 and 25, the same arguments are 
applicable with reference to Claims 1 1 and 12, noting that Claim 24 has been amended to depend 
from Claim 19. Claim 27 is similar with respect to the second location, and has also been 
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amended to depend from Claim 19. Therefore, Applicant believes that claims 11, 12, 24, 25 and 
27 are not unpatentable in view of the combination of Hartman in view of Official Notice. As 
noted, Hartman does not in any way suggest that a second location would be utilized. To do 
such, would unduly complicate the system of Hartman, as the cookie database is typically 
located locally. Therefore, Applicant believes that the official notice is not proper to cure the 
deficiency in Hartman, i.e., that Hartman does not disclose the second location nor does the 
combination of Hartman and Rhoads cure this deficiency. Merely to state that disclosure in one 
document stating that the location is local does not automatically suggest that the location could 
be stored anywhere. Applicant believes that a reference is required to support such a rejection. 

Applicants have now made an earnest attempt in order to place this case in condition for 
allowance. For the reasons stated above, Applicants respectfully request full allowance of the 
claims as amended. Please charge any additional fees or deficiencies in fees or credit any 
overpayment to Deposit Account No. 20-0780/PHLY-24,732 of HOWISON & ARNOTT, L.L.P. 

Respectfully submitted, 
HOWISON & ARNOTT, L.L.P. 
Attorneys for Applicant(s) 

/Gregory M. Howison, Reg. No. 30,646/ 

Gregory M. Howison 
Registration No. 30,646 

GMH/dd/ljo 

P.O.Box 741715 
Dallas, Texas 75374-1715 
Tel: 972-479-0462 
Fax: 972-479-0464 
January 17, 2007 
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